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Abstract. Bitcoin is a peer-to-peer (p2p) electronic cash system that 
uses a distributed timestamp service to record transactions in a public 
ledger (called the Blockchain). A critical component of Bitcoin's success 
is the decentralized nature of its architecture, which does not require or 
even support the establishment of trusted authorities. Yet the absence 
of certification creates obstacles to its wider acceptance in e-commerce 
and official uses. We propose a certification system for Bitcoin that offers: 
a) an opt-in guarantee to send and receive bitcoins only to/ from certified 
users; b) control of creation of bitcoins addresses (certified users) by 
trusted authorities. Our proposal may encourage the adoption of Bitcoin 
in different scenarios that require an officially recognized currency, such 
as tax payments — often an integral part of e-commerce transactions. 

1 Introduction 

Bitcoin is a peer-to-peer (p2p) electronic cash system, first described in [11]. The 
Bitcoin p2p network implements a distributed timestamp service that records 
transactions in a public ledger (called the Blockchain). The timestamp operation 
is computationally expensive, requiring proof-of-work to verify a transaction and 
insert it into the Blockchain. In compensation for this effort, the Bitcoin protocol 
enables the nodes to mint coins, i.e., to add into the ledger transactions for 
self-credit. This distributed minting operation is the source of new currency, 
dispensing with the need of a central issuer. 

Large numbers of users currently transact in Bitcoin, engaging in significantly- 
sized transactions [13]. The decentralized nature of Bitcoin, wherein confidence 
on the integrity of the public ledger arises by the cooperative nature of inter- 
actions between the participants, is a critical component of its success: Bitcoin 
removes the necessity for all involved to agree to trust any single entity. How- 
ever, the converse is also true: Bitcoin does not offer a built-in mechanism to 
incorporate trustworthiness from real-world entities into the system. 

Anonymity In the Bitcoin Protocol. In the Bitcoin Blockchain, users are iden- 
tified only by addresses, which are pseudonymous public key fingerprints. It is 



possible for the user controlling a Bitcoin address to remain unidentified — until 
information is voluntarily revealed during a purchase or in other circumstances. 
For this reason Bitcoin has been at times chosen as a payment medium for illegal 
business. Some governments 4 are also concerned that Bitcoins could be used to 
skirt capital control laws. On the other hand, legitimate users desirous of privacy 
should be mindful of the fact that it is possible to link entities that share cash 
streams — see Ober et al. [13] and Meiklejohn et al. [8] for how an analysis of the 
Blockchain may reveal that the same real-world entity is behind multiple Bitcoin 
addresses. Thus, such users should completely segregate their Bitcoin addresses 
among their different personas. 



Our Contribution: Certifiable Bitcoin Addresses. This paper describes 
an extension of the Bitcoin protocol that preserves its decentralized nature, while 
also enabling payers to optionally specify the involvement of a trusted authority 
that attests to the identity of the payee, by requiring payees to use certified 
Bitcoin addresses. Conversely, we also enable payees to require that a payer uses 
a certified Bitcoin address. More specifically, we introduce the concept of Bitcoin 
addresses that need to be generated with the support of a trusted authority. 
Those addresses are still anonymous within the Bitcoin system, but the authority 
can validate the legitimacy of the entity to whom it releases a certified address 5 , 
and other members of the Bitcoin network can attest to the involvement of the 
trusted authority in issuing the address. These certified addresses are allowed to 
co-exist with the standard auto-generated Bitcoin addresses. 

Certified Bitcoin addresses are blinded: While the trusted authority can mint 
coins on behalf of a particular user, it cannot spend any of them. Certified 
addresses mitigate existing reservations against the adoption of Bitcoin as a 
currency in commercial uses and against acceptance of the Bitcoin payment 
protocol as a fully valid alternative to credit card systems. 



Identity Theft Mitigation. Our proposal also enhances security against identity 
theft in Bitcoin. Indeed, consider the case where a man-in-the-middlc (MITM) 
attacker changes the payee's bitcoin address for the attacker's address. For in- 
stance, the attacker could deface the payee's website to receive payments in- 
tended for the payee. This attack is quite devastating since, in the Bitcoin pro- 
tocol, once the payment is accepted and registered in the ledger, it is impossible 
to revert it (unlike credit card payments). With our proposed solution, the payer 
can first check that the address is certified thus ensuring that the actual identity 
of the attacker could be recovered by the trusted authority in case of dispute. 



4 China [18] has recently declared Bitcoin illegal. 

5 Note that users may be allowed to use simply, e.g., an email address to request 
Bitcoin addresses. In this case, an email address, rather than an actual identity, is 
bound to a Bitcoin address. 



1.1 Outline 



We briefly recall Bitcoin's transaction mechanism. A Bitcoin transaction is a 
cryptographically signed statement that transfers an amount of bitcoins from the 
sender's to the receiver's address. The sender proves ownership of the bitcoins 
by "redeeming" a transaction already in the ledger that moves at least the same 
amount of bitcoins to their address. For more details please refer to Section 3. 

The standard approach to add certified addresses to the Bitcoin system would 
be to use PKI-rooted certificates. A trusted authority would sign each newly re- 
leased certified address by generating an address certificate. This mechanism can 
be adapted into Bitcoin's infrastructure by using the Bitcoin scripting language. 
For a certified address one needs to include a certificate from the central author- 
ity to each transaction: A new transaction redeems the earlier one only if a) it is 
verifiable using the sender' address, as with all transactions; and 6) the attached 
certificate is valid. However, there are some disadvantages to incorporating a 
traditional PKI approach in Bitcoin, to wit: 

1. A noticeable modification on the software is needed. We need a signature ver- 
ification operation that takes as input the certified public key (the message), 
the certificate (the CA's signature on the message) and the public key of the 
CA in order to verify the certificate. However the operation DP_CHECKSIG, 
which in the Bitcoin scripting language provides signature verification, takes 
only two inputs - a public key and a signature - and assumes as message the 
transaction's data. The semantic of OP_CHECKSIG would need to be signifi- 
cantly modified or a new operation would have to be added to the scripting 
language. Any modification of this type would require all the nodes in the 
system to upgrade their software. 

2. In Bitcoin, transaction fees are accounted per bytes: the bigger the size of a 
transaction, the higher the fees to pay. PKFs addition of certificate chains 
to (potentially) each address in each transaction would significantly increase 
transaction costs. 

3. The Bitcoin wallet software must download the entire ledger. Even an in- 
crease of a few gigabytes creates scalability issues, particularly for smart- 
phones or devices with limited bandwidth and data capability. The average 
size for a block is 156KB and the average number of transactions for each 
block is 315, which means that the average size of a transaction is approx- 
imately 507 Bytes. Considering that the size of a signature in the Bitcoin 
system's encoding is 71 Bytes, the transaction size will increase by at least 
14% 6 . Currently, the size of the ledger is approximately 12GB. In the worst 
case scenario, where every transaction is being certified, the ledger would be 
about 1.67 GB bigger. 

It would be preferable to add certified addresses in the Bitcoin system without 
increasing the size of the transactions (and, ultimately, the size of the ledger). 
We achieve this by leveraging the storage and bandwidth cost benefits provided 



By taking the average over all transactions made in 2013. 



by self-certified public keys. In particular, we adapt techniques developed for 
self-certified PKI to work within the Bitcoin system. Compared with a standard 
PKI approach, our solution does not have the drawbacks (2) and (3) outlined 
above. Moreover, even though we still need to update the software of every 
node in the network, the modification to accommodate self-signed certificates 
is easier to accomplish. It can be achieved without changes to the the Bitcoin 
scripting language, or (in alternative implementation) with minimal changes. 
Indeed, our solution is perfectly compatible with the current ledger and both 
systems (standard and certified Bitcoin) can run contemporarily on the same 
ledger. 

1.2 Previous Work 

Previous Work on Bitcoin. As pointed out earlier, the Blockchain allows to link 
entities that share cash streams; and the misconception that pseudonymity pro- 
vides anonymity has been partially unmasked by a series of recent works on the 
Bitcoin transaction's graph, see for example [16,13,1]. Previous research has 
thus focused on strengthening the privacy guarantees afforded by Bitcoin. In [4] 
Barber et al. provide a protocol that features secure mixing of money, ensuring 
money is transferred to fresh, and thus unlinkable, addresses through an un- 
trusted third party. A more radical solution to anonymity is given in the paper of 
Miers et al. [9], where the authors propose an innovative and Bitcoin-compatible 
system where full anonymity is achieved via zero-knowledge techniques. In this 
paper, we focus instead on enhancing trust, via certified bitcoins. Without ad- 
ditional measures, this approach would lower the degree of anonymity in the 
system; but we point out that our solution is compatible with the approaches 
proposed in [4, 9] , allowing for both anonymity and certification within the sys- 
tem. 

Other works have focused on improving the scalability of Bitcoin, particularly 
in what regards the bandwidth required to validate the Blockchain. In [4], the 
authors proposed a secure filtering service that is backward compatible with 
the current system. The filtering service sends only relevant transactions to 
nodes allowing for significant space savings. The service does not increase the 
degree of linkability, and thus has no impact on the privacy of Bitcoin usage, 
but the need of a fully-trusted third party can be a deterrent in the Bitcoin's 
context. Indeed, the filtering service could maliciously hide from the user im- 
portant transactions — the user needs to fully trust the service provider for the 
filtering service. In contrast, the trusted authority in our certification scheme is 
only functionally trusted, and a pure enhancement to the Bitcoin's ecosystem. 
As we shall see in Section 3, the trusted party cannot recover the user secret 
key. In addition, any abuse from the certification authority are detectable via 
inspection of the Blockchain. 

Another line of research has been recently proposed by Andrychowicz et al. 
[2] where a general protocol for secure multiparty computation using Bitcoin's 
transactions is proposed. The system guarantees a form of fairness: if a party 



interrupts the protocol, the outcome is still "tolerable" to the other honest par- 
ties. 



Previous Work on Self- Certified Public Key. Our proposal can be seen as a weak 
version of what is referred to as Self-certified (SC) PKI. SC-PKI contemplates 
public keys that do not need to be accompanied by a certificate in order to be 
authenticated by other users. To the best of our knowledge, the first schemes 
to rely on only functionally trusted authorities were described by M. Girault 
in [7] — where the concept of SC-PKI is itself introduced. That work establishes 
two SC-PKI constructions, one based on RSA and one based on Elgamal-type 
public keys. It has been later shown that RSA constructions suffer from a draw- 
back, namely it is possible for the trusted party to safely generate its keys to 
include trapdoor information that facilitates the recovery of other parties' se- 
crets [17]. This attack applies to every RSA-based construction that results in 
users reconstructing discrete-log type public keys. Therefore, we concentrate on 
the case where the trusted party's public keys are themselves of discrete-log type. 

We note that Girault's SC-PKI schemes are not ideally suited to the desired 
Bitcoin application. The key generation protocol for the Girault's scheme takes 
as common inputs the group's parameters (G, g), the user's identity / and returns 
as the user's public key the tuple (r, r s ) where r € G and the user's secret key 
is S e z q . 

By necessity, the discrete logarithm of r to base g should not be learned by 
the user, for this would leak the trusted authority's private key. As a result, two 
public key pairs (r^,?*^ 4 ) and (rs,r^ B ) of users A and B are computed with 
respect to different bases and r B , respectively. However, this type of public 
key (i.e., an element in G 2 ) does not match the Bitcoin specification. 

Another self-certified public key scheme based on Elgamal signatures and 
provably secure in the Random Oracle Model (ROM) was described by Petersen 
and Horster [14]. The security analysis relies on Pointcheval and Stern's splitting- 
lemma security arguments [15], and thus achieves only a loose reduction to the 
Discrete Logarithm Problem (DLP). 

However, in the Bitcoin setting, a tight proof in the Generic Group Model 
(GGM) is more desirable than a loose proof in the Random Oracle Model. Indeed, 
the Bitcoin protocol already relies on the security of the ECDSA standard — 
which is only shown secure via a GGM (tight) reduction to the Elliptic Curve 
Discrete Logarithm Problem (ECDLP). Our Certified Addresses construction is 
thus a better fit for Bitcoin in that it is similarly provably secure in the GGM 
by a tight reduction to the ECDLP — allowing for the entire security analysis to 
occur within the same well-defined model. 

Ateniese and de Medeiros [3] describe a new self-certified scheme based on 
the Nyberg-Rueppel signature [12] scheme and its variants. The certification 
scheme in Section 3 can be seen as a novel self-certified scheme where the cer- 
tification results from the trusted party applying the modified Nyberg-Rueppel 
signature [3] to the message m = 0. 



Description of contents. On Section 2 we begin by giving a description of Bitcoin 
and its transaction mechanism and then we introduce a few standard crypto- 
graphic concepts and terminology that will be used in later sections. On Section 3 
we present our contribution with a brief description of an implementation. On 
Section 4 we provide the security analysis of our proposal. Lastly, on Section 5 
we give a brief conclusion of the paper. 

2 Background 

In this section, we provide an overview of the Bitcoin system and its transac- 
tion mechanism. We also introduce a few standard cryptographic concepts and 
terminology that will be used in later sections. 

2.1 Bitcoin Signature Scheme 

Bitcoin employs the Elliptic Curve Digital Signing Algorithm (ECDSA) [19] for 
all of its signatures. ECDSA is a widely used and trusted standard, and it has 
been extensively analyzed. While a security proof for ECDSA in the Standard 
Model is not known, it has been proved secure against existential forgery by 
adaptive chosen- message attack in the GGM [5]. 

2.2 Bitcoin Transactions 

In order to generate a new Bitcoin address (the core identifier in the Bitcoin 
protocol), a user first produces a pair of private and public keys for ECDSA: 
(sk,pk). The Bitcoin address relative to (sk,pk) is the hash of the public key, 
namely H(pk), where H is a hash function based on SHA-256 and RIPEMD-160. 
Some extra bytes are appended as a checksum. 

The simplest case is a standard transaction, say with label T n , between a 
sender's address S, with public key pk$, and one recipient address R. The pay- 
load of this transaction, which we denote by [T n ] contains: an input index p 
(which refers to the earlier transaction T p , already committed to the public 
ledger), the amount v n of bitcoins to be transferred, the sender's public key pk$, 
and the receiver's address R. In addition to its payload, the transaction includes 
the sender's signature t on the transaction payload. More precisely, in addition 
to the payload, the transaction includes a small, standard program in the Bitcoin 
Scripting Language that when executed validates the sender's signature on the 
payload, by applying the following simple rules: The signature on T n is valid if 
and only if H(pks) = S and the application of the ECDSA verification algo- 
rithm with public key pk$, message [T„], and signature r succeeds. That alone 
is insufficient for T n to be accepted: In addition, the value v n being transferred 
should not exceed the value v p in the output of the earlier transaction T p . If 
this latter condition holds, then T n can be accepted to redeem transaction T p , 
provided that the transaction T p has not been redeemed earlier (otherwise this is 



an attempt to double-spend the same set of bitcoins, and the transaction should 
be rejected). 

More advance standard transactions with several inputs and several recipient 
address can be defined. Since such transactions are not necessary for the under- 
standing of this paper we skip their description and refer to [2] . Bitcoin allows 
the users to also create non-standard (also called strange) transactions. Strange 
transactions have a validity policy, specifically, a strange transaction T p contains 
in its output a piece of code in the Bitcoin Scripting Language which implements 
a redemption policy. Subsequent strange transaction T n that purports to redeem 
T p should thus supply any necessary inputs for the evaluation of T p 's policy code, 
and the transaction T n successfully redeems T p if the evaluation of T p 's policy 
with inputs provided by T n outputs true (and again under the restriction that 
no earlier transaction had redeemed T p ). 



3 Certified Bitcoin Address 
3.1 Description of the scheme 

In this section we describe our main contribution. First we introduce some math- 
ematical concepts and notation. The additive group of integer residues modulo 
q is denoted by Z q . The Certification Authority (CA), denoted by T, has the 
following public parameters: the description 7 G of a finite group of size q, a gen- 
erator g of G, and an additional element yj of G. The private parameter of the 
CA is the value xj € Z 9 such that yj = g Xj . We also fix a function p from G to 
Zg. This function could be fairly simple, e.g., it interprets the binary encoding 
of an element of G as the encoding of a positive integer. 

(Certified Address) A user U can request a certified address to the certifica- 
tion authority T by jointly executing the protocol Certified Key Generation 
in Table 1. Notice that U samples k uniformly at random in 1 q (and so does 
T for k'). At this point, U computes the secret key x and verifies that 



The certified address A is the value H(c). 

(Signature Verification) Given a self-certified public key c <G G, the signature 
verification process works by first extracting the embedded public key y and 
then using the standard verification. The only operation that needs to be 
added is the extracting procedure (step 2 on the right of Table 1). 

(Certified Transaction) Let S be an address and R a certified address. Before 
sending bitcoins to the address R, the payer S checks whether there already 
exists a transaction redeemed by R in the ledger. Notice that R can ensure 



By description here we mean a (binary) encoding of G and its operations that can 
be programmed into a computer. 
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Certified Bitcoin 


Common inputs: G,g 


Common inputs: G, g, yr 


Standard Key Generation: 


Certified Key Generation: 
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Standard Verification: 


Certified Verification: 


1. Check A = H(y); 


1. Check A = H(c); 


2. Check M^ cdsa {[T],t) 


2. Set y := c ■ y£ (c) 

3. Check Vrf^ CDSA ([T],t) 



Table 1. Comparison between Bitcoin and Certified Bitcoin. In both systems, the 
value A represents the Bitcoin address. The certified key generation is blinded while 
the transaction verification needs only a single extra step (step 2 on the right). All 
operations on the exponents are taken modulo q. 



that such a transaction exists by sending some bitcoins to itself (i.e. a self- 
transaction) . We call the first redeemed transaction of a certified address the 
address certification transaction. 



The correctness of the public key derivation follows: 

x _ k+k'+p(c)x T _ „k+k' _ p(c)x T _ £ _ p(c) 



For a comprehensive list of the possible interactions between standard and 
certified addresses we refer to Figure 1. 
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Fig. 1. Certified Bitcoin transactions: The figure shows all possible types of transac- 
tions in a ledger with both standard and certified bitcoins. In the second block, a bitcoin 
is sent to a newly created and supposedly-certified address. This first self transaction 
in the third block designate that address as indeed certified. In the 5th block, bitcoins 
are sent from a certified address to a standard address. The last transaction is between 
standard bitcoin addresses. 

3.2 Implementation Designs 

Because of how Bitcoin handles transactions internally, it is not possible to check 
that an address is certified by just looking at the transaction script. A standard 
transaction script is shown below: 

scriptPubKey: 0P_DUP 0P_HASH160 <pubKeyHash> 0P_EQUAL VERIFY OP_CHECKSIG 
scriptSig: <sig> <pubKey> 

where scriptPubKey is the input script and scriptSig is the output script. To 
verify a transaction, the following actions are performed: (1) after stacking up 
the signature of the transaction and the redeemer's public key, (2) the latter 
is hashed by the 0P_HASH160 operation and (3) the hashed valued is compared 
with the <pubKeyHash> value. The problem is that such a value is a hash of 
the public key and not a bitcoin address. The operation OP_CHECKSIG is able to 
distinguish whether the address is certified (by applying the certified signature 
verification algorithm), but it has no way to report the type of address to the 
Bitcoin client. 

There are a few ways to implement our proposal into the Bitcoin client. We 
briefly describe three viable options next. 

New operation OP_EXTCERTKEY. For this implementation, we extend the script- 
ing language with a new operation OP_EXTCERTKEY that takes a self-certified 
public key c as input and then extracts the public key y from it, pushing the ex- 
tracted key y into the stack, and then re-using the standard signature operation 
OP_CHECKSIG to verify the signature against the extracted key (now in the stack). 
The size of the transaction would increase by the size of the new operation code 
(1 byte): 



scriptPubKey: OP_DUP 0P_HASH160 <pubKeyHash> OP_EQUAL VERIFY OP_EXTCERTKEY 
OP_CHECKSIG 

New operation OP_CHECKCERTSIG. Instead, we could extend the scripting lan- 
guage with a new operation OP_CHECKCERTSIG that will exclusively handle certi- 
fied transactions by first extracting the public key y from the self-certified public 
key c to later perform the standard signature verification. The transaction script 
for a certified transaction replaces the standard operation OP-CHECKSIG with this 
new operation: 

scriptPubKey: 0P_DUP 0P_HASH160 <pubKeyHash> 0P_EQUAL VERIFY 
QP_CHECKCERTSIG 

Modify the operation OP.CHECKSIG. Another way is to just modify the client to 
interpret each transaction as possibly a certified transaction. In this case, the 
client would first execute the script normally, but if it failed, it would re-attempt 
the execution using the certified transaction algorithm (i.e., performing an oper- 
ation such as OP_CHECKCERTSIG instead of OP_CHECKSIG). The client would then 
report one of (a) successful standard transaction; (b) successful certified trans- 
action; or (c) verification failure accordingly. The Bitcoin scripting language is 
unmodified in this approach. 

3.3 Security Requirements and Goals 

A standard Bitcoin address is sclf-gcncratcd, while a certified address is jointly 
computed with the involvement of the CA. Thus, it is natural to require that 
Bitcoin transactions be hard to forge even by a malicious CA. Another security 
requirement is that certificates must be unforgeable — if the adversary does not 
know the CA's secret key, it cannot generate a certificate and a transaction 
(signature) through that certificate. Certified Bitcoin addresses share some ideas 
with both Self-Certified Public Keys [7] and Blind Signatures [6]. The security 
of our construction holds in the GGM which is the same on which the security 
of standard Bitcoin relies on. This allows us to provide a security analysis of the 
protocol within a single and well-defined model. 

Crucial to our security formulation is the stipulation that an address be 
recognized as certified only after it issues a signature (i.e., there is a certified 
transaction in the public ledger which redeems from it). Indeed, in the absence 
of the burden of demonstrating knowledge of the secret key, it is trivial for an 
adversary to "pretend" to have a certificate, since the output c of an (honest- 
party) execution of the certification protocol is simply an uniformly distributed 
element in G. 

While, by unforgcability of ECDSA, the adversary can not redeem bitcoins 
from the related address, they may still pretend that the address has been cer- 
tified. This attack makes no sense in the context of standard Bitcoin addresses: 
A rational adversary willing to maximize their gain would prefer to exhibit an 



address for which the secret key is known (to be able to spend any received 
coins). In our context, on the other hand, if a malicious user falsely claims that 
an address is certified, it may induce other users to complete unpremeditated 
transactions. 

4 Security of the Certified Bitcoin Addresses 

In this section we provide a formal security experiment that captures the informal 
requirements given in Section 3. Then we show that no ppt generic adversary 
can win the experiment, providing a formal proof of security to our construction. 

We recall that the GGM captures algorithms that access group operations 
(and indeed the group encoding) through black box function calls. The proofs 
are inspired by the techniques described in Naccache et al. [10]. 

In the GGM, the group encoding cr(-) : Z g — > G represents an encoding oracle 
that implements a homomorphism from Z 9 onto G. 

As before, we employ a function p(-) from G to Z q , and via notation overload 
also see p(-) as a function from G to Z 9 . To recall, since a( ) encodes elements 
of G into binary strings, these strings may thus be interpreted as the binary 
expansion of an non-negative integer, and that integer can further be reduced by 
computation of its positive remainder modulo q. 

In this setting, one describes the public key y — g x as {a(l),a(x)}. This 
notation just means that the homomorphism er(-) maps 1 to j and therefore 
maps x to y. a(-) is an exponential notation, so x is unrecoverable from a(x). 

The group operation oracle • © • takes two encoded group elements a(v\), 
ct(i>2), and returns the encoded product a(v\ + v 2 ). (Since this is exponential 
notation, the product translate as a sum in the exponents.) Similarly, given 
o~(v) and an integer u, one can implement the square-and-multiply algorithm 
for exponentiation, using multiple calls to the group operation oracle, to obtain 
a(uv). One also needs a group inversion oracle Qa(v) — > a(—v). 

4.1 Unforgeability Formalizations and Proofs 

We now provide a rigorous definition of security for the construction in 3.1 by 
defining the Signature Unforgeability Experiment. This is an adversarial game 
wherein an attacker may obtain one or more certified addresses by executing the 
protocol with the CA and/or compromise the CA. To succeed in the experiment, 
the attacker needs to produce a valid message-signature tuple for a fresh certified 
public key (i.e., one requested by an honest party to the potentially malicious 
CA). 

Notation: k denotes a security parameter, and poly(fc) a value allowed to grow 
as a polynomial function of k. A stands for the attacker or adversary. CKG^t 
represents the Certified Key Generation protocol described in 3.1, where P is 
some party. In the adversarial game, the adversary has oracle access Oj to the 
trusted party and can execute the protocol CKG^o,-, obtaining new certified 



keys at will. It may also compromise the trusted party directly in which case it 
can execute the protocol CKG^ j entirely as a procedure. 

The adversary may also request that new (honest) parties P be instantiated 
and obtain oracle access Op with which to execute CKGo Pi e> T to produce a 
certified address c for P. Alternatively, if A has compromised T, it can execute 
CKGcip.j, which additionally gives it T's view of P's certificate key generation. 
Finally the adversary can use oracle access Op to request signatures Sign^ DSA (-) 
on arbitrarily chosen messages. The security experiment is described in Fig. 2. 



Exp a X 9 ' unf {k) : 

1. (G,g,x T ,yr) 4- Gen(l fc ) where |G| = poly(fc), and set L <- 0, S <- 0; 

2. A with input G, g, yr has oracle access to T = T(s;t) with which 
can play the protocol CKG. j0t 

Let (c, x) be the output of T after any execution of CKG,a,o t 
L maintains all certificates whose secrets were produced by A 
Update L<- Lu{c}; 

3. Optionally A can extract the secret key xj of the trusted party by 
compromising it; 

4. A may request that arbitrary honest parties P be instantiated. Specifi- 
cally, an oracle machine Op is instantiated and set in pause state; 

5. Through oracle access Op, A may request that CKG<p Pi o T be executed 
to output a certified address c — c P for P (A has bystander view of an 
honest party enrollment); 

6. If A has compromised T, it may request that CKGo Pi t be executed, 
giving A the trusted party view of an honest party enrollment; 

7. A may request that honest party P sign arbitrary messages m of A's 
choice, executing r ^— Sign|, CDSA (m) = SignECDSA P (c P )(m) 

c P'Vj 

Let (cp, m, r) be the output after any such execution 
S maintains the set of signatures directly given to A: 
Update S <- S U {{cp, m, r)}; 

8. Eventually A outputs a triple s = (c, m, r); if 

Vrfy CDSA (m, t) = 1 and c L, and s S 
holds where y — c • yj^ c \ then output 1 else 0. 



Fig. 2. The Exp si9 - unf experiment. 

Informally, we say that an adversary wins an experiment if only if the output 
of the experiment is 1. The security claim is that, under the GGM, there is no 
efficient adversary that wins the Signature Unforgeability Experiment. 

Before stating our first security result, we informally recall the hypothesis of 
the Security Theorem of the ECDSA signature scheme in the GGM (Thrm. 2 
in D. Brown [5]). The theorem holds under the assumptions that the private 



keys and ephemeral keys are uniformly random, the hash function is collision 
resistance and satisfies two other properties called (1) zero-resistance, i.e., an 
adversary cannot find a message that the hash function maps to 0 fe ), and (2) 
uniformity, roughly, the distribution of the output value of the hash function 
on input a uniformly and random message is statistically close to the uniform 
distribution (see [5] for more details) . These two properties are generally believed 
to hold true in practice for cryptographic hash functions in current usage, in 
particular the ones employed in the Bitcoin protocol. 

Theorem 1. If the Bitcoin 's hash function is collision resistant, zero resistant 
and uniform, and the ephemeral keys are uniformly random, then there is no 
efficient, generic adversary that achieves a non-negligible probability of success 
in Exp slg - unf . 

We prove the theorem by transforming the above experiment into related 
ones by reasoning about the adversary view (hybrid argument). 

First, we note that we can assume that A always compromises T right after 
receiving the public parameters. Indeed, the adversarial goal in the experiment 
is the same whether T is compromised or not, and „4's view of the experiment 
is strictly enlarged by directly playing the role of T throughout. 

Now wc look into more detail on the protocol algorithm CKG within the 
GGM. Whenever a party chooses some random value r and needs to compute 
g r G G, it actually needs to consult the encoding oracle for er(r). The encoding or- 
acle in a GGM simulation maintains a list of previously asked for inputs ij it has 
been given and the values it has returned for them: {ii, o\ = cr(ii), . . . ,i n ,a n = 
a(i n )}. If the new input r matches an earlier if, it will return the corresponding 
o~g. Otherwise, it generates a completely new random binary string z, newly de- 
fines a(r) := z and appends to its list {ii, o\, . . . ,i n , a n , i n +\ — r, er„+i = a(r) = 
z}, returning z to the caller. 

We now modify the experiment simulation to Exp_^ . The only differ- 
ence between Exp^J 9 ""^ and Exp^ 9 ~ u ™^ is as follows: When an honest party 
P engages with A (impersonating T) to obtain a certificate, and A generates 
k' and attempts to compute c = hg k = a{k + k'), where k is the randomness 
computed by P; then if the GGM oracle already has some ii — k + k' in its list of 
previously encoded group elements, the experiment Exp^J 9 "™ terminates early, 
with A victorious. Let us call Coll this event. Otherwise, it continues identically 
as Exp^ 9- "™^ , i.e., the GGM oracle computes an entirely new random string 
c = a(k + k') and returns it to A. 

We claim that A's additional probability of success in Exp^ versus 
Exp^ 9 ~ un ^ is negligible. For if the adversary were able to compute k' such that 
k' = if — k for a previously seen ig, it would also be able to extract the discrete 
logarithm k = ii — k' from h = g k , given only h. The claim then obviously fol- 
lows by the standard security assumption of hardness of the Discrete Logarithm 
Problem in elliptic curves (ECDLP). 

SI Q — UTL J 

Within Exp_4 it holds that even when honest party P interacts with a 

malicious trusted party, the protocol execution guarantees that c, and thus the 



random contribution x = k' + p{c) ■ xj of T to P's private key x — x + k is 
uniformly and randomly distributed. 

Specifically, let u be the number of instantiated honest parties P (i.e., u is 
the number of execution of the CKG protocol between an honest party and the 
trusted party) and let e bound the probability that a ppt generic algorithm 
solves the DLP in G, we have that: 
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If ^Coll holds the experiment guarantees that the honest parties private keys 

SXQ — UTL f 

are uniformly and randomly generated. Notice that the experiment Exp^ 
under the condition —.Col I is equivalent to u independent and parallel executions 
of the existential forgery experiment under the chosen-message attack of the 
ECDSA. We now can directly invoke the security of ECDSA in GGM. In fact, 
the private keys are uniformly and random, and by hypothesis, the hash function 
is collision resistance, zero-resistance and uniform and the ephemeral keys are 
uniformly and random. 

Specifically, let e cr h be the probability under collision resistance attack for the 
underlying hash function, then: 
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(k) = 1 <u- (e crs + poly(fc) • e) 



where the poly(/c) depends on the running time of the adversary. 

□ 

In the above we did not prove that the generation of certificates itself was 
unforgeable — indeed, by disclosing T's private key to A we made it trivial for A 
to generate new certificates. Merely proving that a malicious T cannot bias the 
selection of private keys by honest parties was sufficient given that the Bitcoin 
construction requires issuing a signature to complete certificate validation. We 
now consider the issue of unforgeability of certificates separately. 

The property is not strictly necessary to the security of the certified Bitcoin 
address construction, since without a previously seen signature issued by a Bit- 
coin address, it cannot be considered certified. However, it provides evidence that 
our Certified Key Generation mechanism can be used in any cryptographic ap- 
plication, provided that the certificate be accompanied by a proof of knowledge 
of the certificate's associated private key. 

We omit a formal definition of security requirements of self-certified public 
schemes here for conciseness reasons, and instead refer the reader to [7]. More 
specifically, we provide an adversarial-game formulation of security for the fol- 
lowing claim: When the trusted party is honest, adversaries cannot on their own 
generate certificates on public keys for which they know the private key. 



Exp c J rt - unf (k) : 

1. (G,g,xj, yr) Gen(l fe ) where |G| = poly(fc), and set L <— 0; 

2. A with input G, g, yj has oracle access to T = T(xj) with which 
can play the protocol CKG. iC > T 

Let (c, x) be the output of T after any execution of CKG.A,e> T 
L maintains all certificates whose secrets were produced by A: 
Update L^iUfc}; 

3. Eventually A outputs x, c; if 

y — g x — c • y^ , where c ^ L 
holds then output 1 else 0. 



The security claim is that, under the GGM, there is no efficient adversary A 
that wins the Certificate Unforgeability Experiment Exp cer ' - ""^. 



Theorem 2. There is no efficient, generic adversary that achieves a non-negligible 
probability of success in Exp cert ~"™-'\ 

As a generic algorithm, A works as follows: It maintains a list of linear 
polynomials {Fi}, where Fj = on + 13%X, and the coefficients lie in Z 9 . The list 
is initiated as {F\ = 1,F 2 = X}. The algorithm also maintains a list {c^} of 
encodings, initiated as {o~\ — c(l), a 2 = o~(xj)}. At the fc-th time the algorithm 
queries the oracle, it provides the indices i, j and a bit b, and the oracle responds 
with either Uk = <t, © Uj or <n 0 (0Oj), according to the case b = 0 or b = 1, 
respectively. The algorithm adds Ofc and = Fi ± Fj mod 5 to each of the 
respective lists, with the + sign being chosen if b = 0. (So it is the same sign 
as in the definition of in terms of oi and o-j.) Without loss of generality, we 
may assume that the Fi are distinct linear polynomials with coefficients in Z 9 . 
If, during the execution of the protocol, it happens that Fi{x) — Fj(x) mod q, 
with i ^ j, it follows that F — Fi — Fj is a non-zero polynomial, with F(xj) = 0 
mod q. This can allow A to solve it for xj, thus extracting the trusted party's 
secret. If the discrete logarithm is hard in G this can only happen with negligible 
probability, and we can rule out the occurrence of such execution sequences from 
the game simulation (called unsafe sequences in GGM terminology). 

Consider now an algorithm that produces a tuple (c, x), after u queries to the 
group operation oracle. Note that in this case, the verification equation implies 
that c = a{x — p(c) ■ xj). Let e = p(c) and P = x — e ■ X. If P is not in the 
list of oracle queries performed by the algorithm, augment the list by adding 
F u+ i = P at the end, and increment the number of queries u u + 1. 

Let Fj be the unique appearance of the polynomial P in the list, without 
loss of generality. Remind that, from the hardness of DL problem in G, there 
does not exist a index i such that Fi(xj) = Fj(xj) mod q. This implies that the 
group operation oracle may return a random value for <jj , because Fj represents 
a query for a new encoding when the encoding oracle is called at step j. The 
probability that o-j equals c is therefore, no more than 1/|G|, as (almost) all 



values are now equally likely. In other words, the probability that the adversary 
will arrive at such an execution sequence is 1/|G| for each oracle query, and thus 
overall negligible if given only a polynomial number of queries. □ 

Implication of Certificate Unforgeability to Identity Theft Mitigation. Let us 
briefly consider the implications of certificate unforgeability for our construc- 
tion, where the certification authority is functionally trustworthy, and indeed 
collects proofs of (real-world) identity from the entities it certifies. Now, recall 
the attack scenario where a man-in-the-middlc (MITM) attacker changes the 
payee's Bitcoin address for the attacker's address. Since (by the result above) an 
attacker cannot forge certificates, the payee has a recourse to report the fraud 
and bind it to the identity of the malicious party, with cooperation of the CA. To 
provide a full proof of security of this fact we would have to provide (verbose, but 
intuitively straightforward) formalizations of CA functional trust and of identity 
theft in the context of our Bitcoin construction — for reasons of brevity we refrain 
from expanding on it here. 

5 Conclusion 

The decentralized nature of Bitcoin is a critical component of its success. In this 
paper we describe an optional Bitcoin address certification mechanism that in- 
corporates trustworthiness from real-world entities into the system, to mitigate 
against existing reservations to the adoption of Bitcoin as a legitimate currency. 
We describe how to implement the scheme with the current Bitcoin ledger, al- 
lowing certified and non-certified addresses to be used concurrently. In addition, 
we provide a proof of security within an adversarial-game security model, under 
the Generic Group Model of computation. 
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